<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="zh" xml:lang="zh" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Task: Service Design</title>
<meta name="uma.type" content="Task">
<meta name="uma.name" content="soa_service_design">
<meta name="uma.presentationName" content="Service Design">
<meta name="uma.category" content="Discipline:rup_analysis_design_discipline:分析与设计">
<meta name="element_type" content="activity">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../css/default.css" type="text/css">
<script src="./../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../';
					var imgPath = './../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo, '', true, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top">
<div id="page-guid" value="{9EB2B302-79F6-4DF8-AEB7-98E6AC1756DD}"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Task: Service Design</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../images/task.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This task defines and specifies the services and structure of a service-oriented solution in terms of collaborations of contained design elements and external subsystems/interfaces.</td>
</tr>
<tr>
<td>Disciplines: <a href="./../../rup/disciplines/rup_analysis_design_discipline_29760231.html" guid="_ydt62NnmEdmO6L4XMImrsA">分析与设计</a></td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Purpose</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><ul>
    <li>
        To define the services and structure of a service-oriented solution in terms of collaborations of contained design
        elements and external subsystems/interfaces.
    </li>
    <li>
        To document the specification of services.
    </li>
    <li>
        To determine the dependencies and the communication between services.
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Roles</th><td class="sectionTableCell" width="42%"><span class="sectionTableCellHeading">Primary Performer:
								</span>
<ul>
<li>
<a href="./../../rup/roles/rup_designer_BA8DE74E.html" guid="{DB21F5EF-810B-4994-B120-79FA8774FA9D}">设计人员</a>
</li>
</ul>
</td><td class="sectionTableCell"><span class="sectionTableCellHeading">Additional Performers:
								</span></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Inputs</th><td class="sectionTableCell" width="42%"><span class="sectionTableCellHeading">Mandatory:
								</span>
<ul>
<li>
<a href="./../../rup_soa_plugin/workproducts/soa_svce_model_service_1EE4C96C.html" guid="{FF65B0A2-6C53-4F01-9727-AACDB0D542C8}">Service</a>
</li>
<li>
<a href="./../../rup_soa_plugin/workproducts/soa_service_model_623494B9.html" guid="{E24679B7-19F1-483B-A1F1-578839C43888}">Service Model</a>
</li>
<li>
<a href="./../../rup_soa_plugin/workproducts/soa_svce_model_svce_spec_37E89A91.html" guid="{20F06B5E-95D5-422C-AB68-7C213D28533A}">Service Specification</a>
</li>
<li>
<a href="./../../rup/workproducts/rup_supplementary_specification_F5ACAA22.html" guid="{B16C2941-791C-44E6-B353-354109B5C9DE}">补充规约</a>
</li>
<li>
<a href="./../../rup/workproducts/rup_software_architecture_document_C367485C.html" guid="{6F49641A-ED10-47B5-9E5D-3F90A6BF3006}">软件架构文档</a>
</li>
<li>
<a href="./../../rup/workproducts/rup_design_model_2830034D.html" guid="{8CDAEAD4-5E84-4F50-87FD-3240ED047DE7}">设计模型</a>
</li>
</ul>
<ul></ul>
</td><td class="sectionTableCell"><span class="sectionTableCellHeading">Optional:
								</span>
<ul>
<li>
<a href="./../../rup/workproducts/rup_project_specific_guidelines_8DC8DA32.html" guid="{E5501201-7EE6-4243-AE91-73880FF76FC1}">特定于项目的指南</a>
</li>
</ul>
<ul></ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Outputs</th><td class="sectionTableCell" colspan="2">
<ul>
<li>
<a href="./../../rup_soa_plugin/workproducts/soa_svce_model_service_1EE4C96C.html" guid="{FF65B0A2-6C53-4F01-9727-AACDB0D542C8}">Service</a>
</li>
<li>
<a href="./../../rup_soa_plugin/workproducts/soa_service_model_623494B9.html" guid="{E24679B7-19F1-483B-A1F1-578839C43888}">Service Model</a>
</li>
<li>
<a href="./../../rup_soa_plugin/workproducts/soa_svce_model_svce_spec_37E89A91.html" guid="{20F06B5E-95D5-422C-AB68-7C213D28533A}">Service Specification</a>
</li>
<li>
<a href="./../../rup/workproducts/rup_design_model_2830034D.html" guid="{8CDAEAD4-5E84-4F50-87FD-3240ED047DE7}">设计模型</a>
</li>
</ul>
<ul></ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Steps</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="sectionTableSingleCell">
<div class="stepHeading"> Reuse Enterprise Service Portfolio </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Reuse_Service_Portfolio" name="Reuse_Service_Portfolio"></a> 
<p>
    One of the often stated advantages to the use of a Service-Oriented Architecture (SOA) is the ability for services to
    represent reusable assets across the enterprise, rather than the development of components only within the scope of a
    single application.This enterprise view is important because it embodies the notion that a truly service-oriented
    architecture for IT provides all infrastructure and business capabilities as services and that the applications
    developed by the enterprise reuse capabilities from the portfolio of services.
</p>
<p>
    So, in starting a project it is important to know if you are developing services as part of the portfolio or whether
    you are developing application functionality that uses these services. For example, the development of a portal site
    for customers to access their account information is an application-development project using services in the portfolio
    for customer information, account information, offers, and more. In each case, the use of the portfolio has different
    implications; the service designer is describing their service specification and publishing it as a part of the
    portfolio. This specification allows application developers to understand the interaction requirements for the service.
    The service implementer may now use the same service specification to develop one or more implementations of the
    service, ensuring that the implementation conforms to the specification.
</p>
<p>
    For more information see the concept <a class="elementLink" href="./../../rup_soa_plugin/guidances/concepts/service_portfolio_52FD64AC.html" guid="1.851952881072508E-305">Service Portfolio</a>.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Use Design Patterns and Mechanisms </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Use Design Patterns and Mechanisms" name="Use Design Patterns and Mechanisms"></a> 
<p>
    Use design patterns and mechanisms as suited to the service being designed and in accordance with project design
    guidelines.
</p>
<p>
    Incorporating a pattern or mechanism is effectively performing many of the subsequent steps in this task, but in
    accordance with the rules defined by the pattern or mechanism.
</p>
<p>
    Note that patterns and mechanisms are typically incorporated as the design evolves and not just as the first step in
    this task. They are also frequently applied across a set of model elements, rather than only to a single element.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Describe the Logical Organization of the Solution </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Describe_Logical_Organization" name="Describe_Logical_Organization"></a> 
<p>
    It is frequently useful to organize your thinking in terms of different views into a system and how the services you
    are developing fit into these views. In defining the logical organization views, it is important that assignment of a
    service into a view does not imply ownership in a Unified Modeling Language (UML sense or containment; that is, that
    the same service shall be able to participate in multiple logical views. The organizational views are worth laying out
    in the model ahead of the service development or at least the first iteration of these views so services can be
    assigned to views as identified. In the service model, we use an model element <i><a class="elementLink" href="./../../rup_soa_plugin/workproducts/soa_svce_model_svce_partn_DC19AD3F.html" guid="{C302AF5A-1591-4F26-94E5-C412866553BF}">Service Partition</a></i> to represent an aspect in a view. These
    partitions can be used to represent any number of different perspectives of the solution. For more information, see the
    concept <i><a class="elementLink" href="./../../rup_soa_plugin/guidances/concepts/solution_partitioning_352116F8.html" guid="1.6501323286225543E-305">Solution Partitioning</a></i>, but, importantly, do not imply ownership of the services
    assigned to them.
</p>
<p>
    It is also possible that these partitions, at least those representing key viewpoints, may reside in models separate
    from the services themselves, allowing for the partition models to evolve independently.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Describe Service Elements </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Describe_Service_Elements" name="Describe_Service_Elements"></a> 
<p class="MsoBodyTextIndent">
    As is always the case when looking at modeling software systems, there is a plurality of entry points to any such
    model, any number of representations that can be used, and of course many methodologies one might apply. In most cases,
    these entry points are due to specific concerns in either the technology or business domains that have to be addressed.
    These concerns are important enough to act as starting points because understanding them and the interaction between
    them is critical to achieving success.
</p>
<p class="MsoBodyTextIndent">
    It was our observation that there are a small number of such concerns in developing service-oriented solutions; the
    following diagram represents these primary concerns as specific design tasks. While noting that each of these concerns
    can act as the starting point for service design, and that each approach tends to be well optimized for a certain class
    of services, it is most likely that any large project would use a combination of approaches in the identification and
    design of services.
</p>
<p align="center">
    <img height="115" alt="Diagram is described in the textual content." src="./../../rup_soa_plugin/tasks/resources/co_soa_policy-02.gif" width="241"     border="0" />
</p>
<p>
    For more information see the task <i><a class="elementLink" href="./../../rup_soa_plugin/tasks/identify_services_565F8B8A.html" guid="{0BF79161-A484-4C48-B72D-DA381DA05886}">Identify Services</a></i>, which presents a set of detailed techniques
    supporting these approaches.
</p>
<h4>
    <a id="Message_Design" name="Message_Design">Message Design</a>
</h4>
<p class="MsoBodyTextIndent">
    In this approach, the focus is very much on the service domain. Techniques such as domain engineering or
    object-oriented analysis and design provide much insight into the development of abstract domain models. This focus
    generally produces highly reusable models for message schema. The service design is usually a secondary activity
    although it is sometimes done in parallel. In Electronic Data Interchange (EDI), for example, there is no real notion
    of a service interface because EDI systems usually have a single global inbox and outbox for messages.
</p>
<p class="MsoBodyTextIndent">
    An example of such an approach might be in the traditional business-to-business arena, typified by EDI standardization.
    In this case, the focus of the design activity is the development of message schema agreed upon in some industry or
    other scope and is deemed to be representative of the schema of a class of messages, for example, and industry
    standards such as ACORD, SWIFT, and RosettaNet.
</p>
<h4>
    <a id="Service_Design" name="Service_Design">Service Design</a>
</h4>
<p class="MsoBodyTextIndent">
    In this approach, the designer is concerned with exposing, as a service or set of services, functionality expected of
    the business or application. In this case, we do not necessarily know what the client of the services will choose to do
    with our service, but we do know the kinds of interactions such clients will expect. Therefore, messages tend to be
    secondary and are developed in response to the requirements of an operation.
</p>
<p class="MsoBodyTextIndent">
    An example of this approach would be the Web Services APIs presented by companies such as <u>Amazon</u> and
    <u>eBay</u>. Such service interfaces do not impose a business process on the client. In most cases the do not even
    impose required interfaces on the client, but they expose the operations of their respective service providers in a
    clear and intuitive way to third-party developers.
</p>
<p class="MsoBodyTextIndent">
    As mentioned above, service-centric modeling often lends itself well to a use-case driven approach by understanding the
    needs of actors, the external clients of the service, and providing operations that support these needs, operations
    such as browsing catalogs, adding items to a shopping cart, checking out, and so on.
</p>
<h4>
    <a id="Collaboration_Design" name="Collaboration_Design">Collaboration Design</a>
</h4>
<p class="MsoBodyTextIndent">
    In a collaboration design, the focus is on the collaboration of two or more services; this is very much a process view
    of the services and is related to more traditional business modeling than it is to a software development activity. In
    this approach, services are seen as fulfilling roles in the collaboration and the service specification is therefore
    the set of responsibilities defined for the role across one or more collaborations.
</p>
<p class="MsoBodyTextIndent">
    Such an approach would be recognizable to those that have been involved in the development of RosettaNet Partner
    Interchange Processes (PIPs) or in the development of the OAGIS standards, although the collaborations are less than
    complete in these cases. Such an approach would be common within a business in terms of either business-process design
    or in business-integration activities where the components of an IT system are exposed as services.
</p>
<p class="MsoBodyTextIndent">
    In this case, it is usually the case that the service specification can be derived directly from the collaboration, but
    this approach tends to focus less on message content leading to a requirement for a hybrid approach for completeness.
</p>
<h4>
    <a id="Policy_Identification" name="Policy_Identification">Policy Identification and Capture</a>
</h4>
<p>
    Policy is a broad term that we use here to cover statements or constraints that can be considered non-functional
    requirements. At the level of this model, we have to realize that we do not want the model to be populated with
    detailed statements about technical information but more realistically, we capture the intent of the system in regard
    to these requirements. For example, we may know that a certain message has to be transmitted and kept private as our
    customers' personal details are included; we want to capture the intent that the message be private, not that we
    require data encryption using AES 128 bit encryption over a canonical XML data set with X.509 certificates for public
    key encryption, mainly because very few people will know what this means, let alone be able to specify it in a model at
    this level of abstraction.
</p>
<p>
    The following diagram demonstrates the association of policy with the elements of the <i><a class="elementLink" href="./../../rup_soa_plugin/workproducts/soa_service_model_623494B9.html" guid="{E24679B7-19F1-483B-A1F1-578839C43888}">Service Model</a></i>. Note that policy information may be attached to
    information other than the specification components identified below, although this is the primary area of interest.
</p>
<p align="center">
    <img height="205" alt="Diagram is described in the textual content." src="./../../rup_soa_plugin/tasks/resources/co_soa_policy-01.gif" width="329"     border="0" />
</p>
<p>
    For more information on modeling security policy, see the white paper <i><a class="elementLinkWithUserText" href="./../../rup_soa_plugin/guidances/whitepapers/modeling_security_concerns_in_service-oriented_architectures_3961AE50.html" guid="1.328991553095394E-305">Modeling Security Concerns in Service-Oriented Architecture</a></i>.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Describe Service Dependencies </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Describe_Dependencies" name="Describe_Dependencies"></a> 
<p>
    As a part of the service model, a number of dependencies are naturally captured. These can be as obvious as the
    relationship between a service and its specification or more complex, such as the logical relationship between two
    independent services because they both implement the same specification. These dependencies may often be a part of the
    decision process a service client has to go through in choosing to reuse a service, particularly if there are multiple
    implementations to chose from.
</p>
<p>
    The kinds of dependencies/associations in the service model that are important as listed below.
</p>
<ul>
    <li>
        The relationship between a service and the Service Providers that implements it.
    </li>
    <li>
        The relationship between a service and the Service Specification it implements.
    </li>
    <li>
        The relationship between a service and any Service Specification it requires.
    </li>
    <li>
        The relationship between a service and any Service Channel that connects it to other services and therefore the
        service on the other end of the channel.
    </li>
    <li>
        The relationship between a service and any Service Partition in which the service appears.
    </li>
</ul>
<p>
    It is therefore important that all service specifications be complete, not only with respect to the operations and
    messages they provide, but also any dependencies such as required interfaces for callback operations. The report <i><a class="elementLink" href="./../../rup_soa_plugin/guidances/reports/service_dependencies_D8D49422.html" guid="1.2262765587812462E-305">Service Dependencies</a></i> provides an overview of the important dependencies for the
    service model.
</p></td>
</tr>
</table>
</div>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">More Information</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Concepts</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../rup_soa_plugin/guidances/concepts/service_composition_and_choreography_41EDEECB.html" guid="7.723783423994501E-306">Service Composition and Choreography</a>
</li>
<li>
<a href="./../../rup_soa_plugin/guidances/concepts/service-oriented_architecture_8328ABAD.html" guid="8.613638237693525E-307">Service-Oriented Architecture</a>
</li>
<li>
<a href="./../../rup_soa_plugin/guidances/concepts/solution_partitioning_352116F8.html" guid="1.6501323286225543E-305">Solution Partitioning</a>
</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Tool Mentors</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../rup_soa_plugin/guidances/toolmentors/creating_svce_model_using_rsa_FEA6D4E6.html" guid="{23A022B3-1564-406B-88B5-E8312C764A82}">Creating a Service Model using RSA</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright">Copyright &copy; 2008 版权所有 东软集团股份有限公司&nbsp; 联系邮箱:<a href="mailto:tcoe@neusoft.com">tcoe@neusoft.com</a></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
